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Sir: 

In response to the Final Office Action in the above-identified application, and pursuant to 
the Notice of Appeal filed April 27, 2005, Applicants submit this Brief with the fee of $500.00 set 
forth by 1.17(c). A Petition for Extension of Time and the required fee of $120.00 requesting a 
one-month extension has been concurrently filed herewith extending the period for filing this 
brief to July 27,2005. 

(I) Real Party In Interest 

The real party in interest in this appeal is the assignee UNX, Inc. 

(II) Related Appeals and Interferences 

The undersigned attorney, the appellant and the assignee know of no related appeals or 
interferences which would be directly affected by or directly affect or have a bearing on the 
Board's decision in this appeal. 

(III) Status of Claims 

Claims 1-42 are currently pending, claims 32 and 42 have been withdrawn from 
consideration, claims 1-31 and 33-41 stand finally rejected are appealed. Claims 1-31 and 33- 
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41 are each independently patentable over the prior art, as discussed in detail below, and do not 
stand or fall together. 

(IV) Status of Amendments 

No amendments have been filed subsequent to the final rejection. 

(V) Summary of the Claimed Subject Matter 

The present invention is involved with a system (see figure 1) that is used to trade 
baskets of fungible goods, such as stocks, bonds, limited partnership interests, bank loan 
syndication interests, etc. A basket is like stock in that it has characteristics of permanence so 
that it can be traded as a unit (see specification pg. 3, Ins. 4-9, pg. 5. Ins. 20-26 and pg. 6, Ins. 
24-28). For example, a user can access and obtain a basket created by another person, such 
as "matt's Top 20" (see figure 4). The system (see specification pg. 5, In. 14+) includes an 
interface that shows different views and tools. The interface is presented to the user on a user 
personal type computer 2 that interacts with a sender 3 to send any basket trade order with a 
single trading initiation using a window control (266 - figure 4) and in a single transaction. The 
server receives the single transaction basket trade order and then creates the necessary goods 
trade orders for the markets where the goods are traded. That is, the server 3 communicates 
with the various markets 5-6 or market platforms that trade the goods, such as stocks, of the 
basket trade transaction. The server is better equipped to do this operation than the slower 
personal computer. The system includes a database with basket and asset records (see figures 
26, 26a, 19 and 20, pg. 21, In. 13+, pg. 24, In. 4+). When a trade is completed the server sends 
the user an electronic confirmation message (see figure 8. pg. 14, In. 15+) that provides, among 
other information, the net asset value of the basket. 

The server 3 also prepares and provides the views to the personal computer 2 that are 
used by the user/trader. A version of the interface includes a close control 50 (figure 4) that 
when activated closes or disposes (buy/sell as needed) of the basket (see pg. 10, In. 18+, 
particularly pg. 11, lines 11-14). The user can select individual assets to close (see figure 10, 
pg. 16, In. 27+). The interface includes a basket creation region 98 where the user can list the 
goods (see figure 5, pg. 12, In. 10+). The user can specify a particular destination for the trade 
of a particular good, see for example "ISLD" (Island Trading platform) of figure 6 (pg. 23, In. 19+) 
when the user has a special relationship with a particular trading market, such as a discount on 
each trade. 
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The interface also allows the user to specify other characteristics of the basket trade, 
such as lot size, share threshold or the minimum increment of share trades (10, 100, etc.), a 
measurement index, asset weighting for the basket such as weighted by dollar or number of 
shares, etc. (see figure 5, pg.12, In. 10+). Other conditions can be specified via the interface 
(see figure 22, pg. 22, In. 24+), such as a price limit, a variance that allows a trade to be made 
even if there is not an exact match between all of the assets of the basket and those available in 
the markets, a stop condition that indicates when the order can be placed on an a market or 
electronic crossing network (ECN), etc. 

The interface includes a summary view 40 (see figure 4, pg 10, In. 19+) that shows all of 
the baskets owned by the user and baskets that the user can own or potential baskets that are 
staged in a gallery. 

Master and sub-account relationships are allowed and trades can be proportioned 
between the master and the sub-accounts (figures19-21, pg. 21, In. 13+). 

Baskets can be balanced using a basket balancing view/tool (see figure 9, pg. 15, In. 5+) 
that allows the user to return a basket to its original proportions when it becomes unbalanced 
based on market conditions. For example, when a stock improves in value such that it 
constitutes a higher proportion of the basket than originally designed. The user can adjust the 
weight, trade increment, etc. for the rebalancing. 

A basket detail view is provided (see figure 13, pg. 18, In. 14+) that shows all of the 
assets of the basket and the various information about the basket, such as whether the asset is 
long or short (B/S). 

An asset order view is also provided (see figure 14, pg. 18, In. 23+) that shows the 
details of the asset orders such as the time and date ordered. 

A trade execution view (see figure 15, pg. 19, In. 2+) that shows the details of the 
execution of the order of the assets, such as showing that an order for AOL was filled by two 
trades of 29 shares each 5 seconds apart. 

A basket trade history view is provided (see figure 16a-16g, pg. 19, In. 7+) that shows the 
open/close dates of baskets, changes in the basket, such as size, etc. 

The user can access an asset search view (see figures 11 and 12, pg. 17, In. 21+) that 
allows a user to, for example, find all of the baskets that contain a particular good, such the 
stock of Cisco. 
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Via an asset move view (see figure 17. pg. 19, In. 25+) the user is allowed to move 
assets between baskets. 

A basket rotate view (see figure 18, pg. 20, In. 8+) the user can rotate assets between 
baskets which involves trading assets that need to be bout or sold and moving assets that need 
not be traded. 

Gallery baskets, or baskets that are staged for trading can be viewed in a gallery view 
(see figure 23, pg. 23, In. 16+) that shows the relative position or variance of the basket with 
respect to the trade criteria of the user. 

(VI) Grounds Of Rejection To Be Reviewed On Appeal 

Claims 1-31 and 33-41 stand rejected as being unpatentable under 35 USC section 103 
over Belzberg (6,134,535) in view of Stallaert (6,035,287). (Claims 32 and 42 stand withdrawn.) 

(VII) Argument 

Claims 1-31 and 33-41 stand rejected as being unpatentably obvious under 35 USC 
section 103 over Belzberg (6,134,535) in view of Stallaert (6,035,287). This is not the case as 
discussed below. 

A. The Law 

Claims are not to be read in a vacuum, and limitations therein are to be interpreted in 
light of the specification in giving them their broadest reasonable interpretation (see Application 
of Okuzawa, 537 F.2d 545, 548 (U.S. Court of Cust. & Pat. App. 1976)). Words in the 
specification are given the same meaning when used in a claim (see McGill Inc. v. John Zink 
Co., 736 F.2d 666, 674 (Fed. Cir. 1984)) 

Under Graham v. John Deere Co. . 383 U.S. 1,148 U.S.P.Q. 459(1966) the scope and 
content of the prior art are to be determined, the differences between the prior art and the claims 
at issue are to be ascertained and the level of skill in the art is to be ascertained. Against this 
background the obviousness of the subject matter is determined. 

Obviousness cannot be established by combining the teaching of the prior art to produce 
the claimed invention, absent some teaching or suggestion supporting the combination. Under 
section 103, teachings of references can be combined only if there is some suggestion or 
incentive to do so. (See ACS Hospital Svstems. Inc. v. Montefiore Hospital . 221 USPQ 929, 932, 
933 (Fed. Cir. 1984)) 
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The prior art must not only suggest the desirability that the teachings of references be 
combined but must also suggest the desirability of the modifications in the manner proposed by 
the Examiner as well as the results to be achieved (see Ex parte Costa . 21 1 U.S.P.Q. 
636(P.O.Bd.App.1978), ACS Hospital Systems. Inc. v. Montefiore Hospital . 732 F.2d 1572,221 
U.S.P.Q. 929(Fed.Cir.1984), In re Gordon , 733 F.2d 900,221 U.S.P.Q. 1125(Fed.Cir.1984), Lear 
Siegler V. Aeroauip Corp. . 733 F.2d 881,221 U.S.P.Q. 1025(Fed.Cir.1984) and Diversitech v. 
Century Steps .850 F.2d 675,7 U.S.P.Q.2d 1315(Fed.Cir.1988)). 

To set forth a prima facie obviousness case, evidence of motivation must be provided 
indicating why one skilled in the art would be motivated, lead, or suggested to modify an existing 
reference in view of another reference. In addition, is also improper to base a rejection on the 
claimed feature being merely a design choice. See In re Garrett, 1986 Pat. App. LEXIS 8 (Bd. 
Pat. App. 1986), where the U.S. Patent and Trademark Office Board of Patent Appeals and 
Interferences ("Board") specifically stated: "the examiner has not presented any line of reasoning 
as to why the artisan would have been motivated to so modify the... structure, and we know of 
none. The examiner's assertion... that the proposed modification would have been 'an obvious 
matter of engineering design choice well within the level of skill of one of ordinary skill in the art* 
is a conclusion, rather than a reason." Similar discussions can be seen in In re Chu, 36 
USPQ2d 1089 (Fed. Cir. 1985). 

The Examiner bears the initial burden of establishing a prima facie case of obviousness. 
See In re Rilckaert . 9 F.3d 1531, 1532, 28 USPQ2d 1955, 1956 (Fed. Cir. 1993). A prima facie 
case of obviousness is made by presenting evidence that the "reference teachings would appear 
to be sufficient for one of ordinary skill in the relevant art having the references before him to 
make the proposed substitution, combination or other modification." In re Lintner . 458 F.2d 1013, 
1016, 173 USPQ 560, 562 (CCPA 1972); In re Lalu . 747 F.2d 703, 705, 223 USPQ 1257, 1258 
(Fed. Cir. 1984). It is incumbent on the Examiner to state how and why the teachings of the 
references would have been combined. "If examination at the initial stage does not produce a 
prima facie case of unpatentability, then without more the applicant is entitled to grant of the 
patent" In re Oetiker . 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). 

The Examiner may state that the motivation may be based on knowledge generally 
available to those skilled in the art. This is true. However, the knowledge of those of ordinary 
skill in the art is normally demonstrated by a reference. See In re Kaplan . 789 F.2d 1574, 1580, 
229 USPQ 678, 683 (Fed. Cir. 1986) ("Even if obviousness of the variation is predicated on the 
level of skill in the art, prior art evidence is needed to show what that level of skill was."). At a 
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minimum, the Examiner is required to explain (i.e., make appropriate factual findings) as to what 
one skilled in the art would have known that would have provided the motivation. See In re 
Rouffet . 149 F.3d 1350, 1358, 47 USPQ2d 1453, 1459 (Fed. Cir. 1998) ("[E]ven when the level 
of skill in the art is high, the Board must identify specifically the principle, known to one of 
ordinary skill, that suggests the claimed combination."). 

Any reference used to reject a claim must itself be enabling for the subject matter of the 
invention alleged to be taught (see In re Wilder 429 F.2d 447,166 U.S.P.Q. 545(C.C.P.A. 1970) 
and In re Collins . 462 F.2d 538,174 U.S.P.Q. 333(C.C.P.A. 1972)). 

It is inappropriate to rely on general principles of engineering or physics or common 
understanding to fill in the gaps in the teachings of a reference (see Panduit v. Dennison , 774 
F.2d 1082,227 U.S.P.Q. 337(Fed.Cir.1985) and Akzo v. Dupont . 810 F.2d 1148,1 U.S.P.Q.2d 
1704(Fed.Cir.1987)). 

Factors to be considered in determining that claims are not obvious include unexpected 
results, new features, solution of a different problem and novel properties (see In re Wright 848 
F.2d 1216, 6 U.S.P.Q.2d 1959(Fed.Cir.1988)). 

The fact that the prior art teaches away from an invention is evidence that the invention is 
not obvious (see Akzo v. USITC, 808 F.2d 1471,1 USPQ2d 1241(Fed.Cir.1986) and In re 
Graselli. 713 F.2d 731,218 USPQ 769(Fed.Cir.1983)). 

Hindsight cannot be used in determining the issue of obviousness and the reviewer must 
view the prior art without reading into that art the teachings of the application or patent (see 
Kalman v. Kimberlv Clark Corp. . 713 F.2d 760,218 U.S.P.Q. 781(Fed.Cir.1983)). 

"|T]he best defense against the subtle but powerful attraction of a hindsight-based 
obviousness analysis is rigorous application of the requirement for a showing of the teaching or 
motivation to combine prior art references .... Combining prior art references without evidence 
of such a suggestion, teaching, or motivation simply takes the inventor's disclosure as a 
blueprint for piecing together the prior art to defeat patentability-the essence of hindsight." In re 
Dembiczak . 175 F.3d 994, 999, 50 USPQ2d 1614, 1617 (Fed. Cir. 1999). 

To imbue one of ordinary skill in the art with knowledge of the invention in suit, when no 
prior art reference or references of record convey or suggest that knowledge, is to fall victim to 
the insidious effect of a hindsight syndrome wherein that which only the inventor taught is used 
against its teacher (see W.L. Gore & Associates. Inc. v. Garlock. Inc. . 220 USPQ 303. 312-13 
(Fed. Cir. 1983), cert, denied . 469 U.S. 851 (1984)) 



6 



All of the limitations in the claim must be addressed. See In re Wilder 429 F.2d 447. 
450, 166 USPQ 545, 548 (CCPA 1970) ("every limitation positively recited in a claim must be 
given effect in order to determine what subject matter that claim defines"); In re Wilson . 424 F.2d 
1382, 1385, 165 USPQ 494, 496 (CCPA 1970) ("All words in a claim must be considered in 
judging the patentability of that claim against the prior art."). 

To establish inherency, the extrinsic evidence must make clear that the missing 
descriptive matter is necessarily present in the thing described in the reference, and that it would 
be so recognized by persons of ordinary skill in the art (see Continental Can Co. v Monsanto 
Co. , 948 F.2d 1264, 20 USPQ2d 1746 (Fed. Cir. 1991)). 

Inherency may not be established by probabilities or possibilities. The mere fact that a 
certain thing may result from a given set of circumstances is not sufficient (see In re Olerich . 666 
F.2d 578, 212 USPQ 323 (CCPA 1981)) 

B. The Rejection 

In the final Action of October 27, 2004, on pages 2-4 the Examiner rejected claims 1-31 
and 33-41 stating: 

Claim Rejections - 35 USC § 103 

Claims 1-31 and 33-41 are rejected under 35 USC 103(as) as being 
unpatentable over Belzberg *535 in view of Stallaert et al. '287. 
Belzberg *535 discloses, makes obvious, or inherently teaches 
routing a fungible goods trade order (/.e., stock trade order) to an 
automated trade matching system (i.e., NASDAQ) as a market 
matching order (See, for example. Col. 3, lines 20-32); the system 
further teaching basket trades (Col. 2, lines 29-32) using a single 
initiation action (i.e., single key stroke; Col. 3, lines 51-67). 

Belzberg *536 lacks the specific teaching of a weighting field allowing a user 
specific weighting, and limit pricing. 

Stallaert et al. *287 teach a similar system and hardware configuration including: 
a weighting field (for example, step 203), and limit pricing. 

It would have been obvious to one of ordinary skill in the art at the time of the ^ 
invention to modify Belzberg to include specified weighting and limit pricing, in 
view of Stallaert et al., in order to "squeeze out inefficiencies associated with the 
fragmented market" (See Stallaert et al.. Col. 2, lines 18-20). 

Re claims 6, 8-15, 19-29, 35-36 and 39-41: the limitations not clearly disclosed in 
Belzberg are limitations that are well known in asset trading, and to modify 
Belzberg to incorporate any of the limitations would have been an obvious design 
choice to one of ordinary skill in the art at the time of the invention to achieve a 
desired result. 
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Response to Arguments 

Applicant's arguments filed 7/30/2004 have been fully considered but they are not 
persuasive. 

Applicant argues on page 11 , second paragraph, last two lines, of his response 
that his invention is "not limited to selling/buying of stocks only when 
parameters specified by the user are met". This limitation, however, is not 
found in the claim. 

Applicant further argues on page 12, paragraph two, that the present invention 
provides a weighting field "that is not limited to trading only when a surplus 
exists". This limitation, however, is not found in the claims. 

Although the claims are interpreted in light of the specification, limitations from the 
specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181 , 
25 USPQ2d 1057 (Fed. Cir. 1993). 

All of the limitations, as presently written, are anticipated by the combination of 
prior art, whether viewed alone or in view of obvious design choices well known in 
the art. The applicant is directed to well known asset trading web sites such as 
E-trade and Scotttrade for references teaching what is well known in the art. 

With regards to other limitations argued by applicant (for example limitations in 
claim 26 and 36), the Applicant has failed to argue that the obvious design 
choice used by the Examiner is in some way inaccurate or incorrect. 

Therefore, the rejections have been maintained. 

The arguments with respect to newly submitted claim 42 are moot in view of the 
above withdrawal from consideration. 
(See Action, 10/27/2004, pages 2-4, bold emphasis by the Examiner) 

The portions of the references particularly noted by the Examiner in the rejection 
specifically state: 

Thus, the purchase or sale of a basket comprising various numbers (volumes) of 
a variety of shares can be executed in a matter of seconds before the price or 
other conditions have changed. 
(Belzberg, col. 2, lines 29-32) 

In the embodiment illustrated in FIG. 2, the trader/operator can enter the symbol 
representing the stock in the area 12 followed by the price at which the 
transaction is to be completed in space 14 (which may be a selected price or the 
bid offer or last price derived from the CATS data). Then the size of the order (or 
volume of the transaction) may be indicated in space 16 by selecting the 
appropriate nominal figures 1 ,000, 5,000. 1 0,000, 50.000 or by inserting the 
precise volume in the box 18. Many of the instruction choices provided by this 
interface (such as bid, offer, last, ID, volume, exchange, transaction) may be 
entered without keying by using a mouse as illustrated at 10 in FIG. 1, which 
directs a cursor or indicator to the command. 
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(Belzberg. col. 3, lines 20-32) 



By means of the software of this invention, the terminal or personal computer 
illustrated in FIG. 1 can be used to connect the spreadsheet of the system to the 
data base of the stock exchange mainframe and display the information 
(including symbol, volume of shares, bid, first and last price) in the area 30 of the 
display screen of the terminal as shown in FIG. 3. For purposes of trading an 
index or custom basket of shares, the display will contain the information with 
respect to the shares included in the index or basket as illustrated. The system 
then executes a dynamic data link to the spreadsheet which causes the 
spreadsheet to read the list of stocks to the multiple order trading system of the 
present invention. In the next step the system captures the spreadsheet data and 
makes each stock price and volume a variable that is inserted in a list of 
preprogrammed commands. The list is then sent to the order entry system of the 
stock exchange with a single key stroke. 
(Belzberg, col. 3, lines 51-67) 

WEIGHT ASSET PORTIONS BY ALLOCATION VALUES 
(Stallaert, figure 3, reference block 203) 

The bundle trading market would allocate price between the resources 
exchanged. Such a bundled trading mechanism also would squeeze out 
inefficiencies associated with the fragmented market for these resources. 
(Stallaert, col. 2, lines 18-20) 

It is submitted that the rejection is defective as a matter of law and does not present a 
prima facie case of obviousness. 

For example, the Examiner has referred the applicant to the current trading sites of E- 
Trade and Scottrade for what is well known. These current sites are not prior art and the 
Examiner has provided no evidence that these sites are somehow prior art. 

As another example, the Examiner has provided no comments or rationale for the 
rejection of a number of the claims, for example, claim 2. 

As further example, on page 4 of the Action the Examiner has based the rejections of 
claim 26 and 36 on allegations that the features of the invention are based on design choice. 
Design choice is a choice between two alternatives that will make no difference to the 
functioning of the invention. That is, one choice over another provides no advantages. As noted 
above a rejection based on design choice is improper where the Examiner has provided no line 
of reasoning as to why the artisan would have been motivated to so modify the structure of the 
prior art into the invention. The Examiner has provided no such reasoning. And it is submitted 
that the features of the claims being rejected based on design choice do provide advantages as 
discussed with respect to claims 26 and 36 below. 
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In rejecting claims that recite weighting and limit pricing, the Examiner has cited as 
motivation, for those of ordinary skill in the art to modify Belzberg and Stallaert to include such, a 
statement in Stallaert concerning squeezing out market inefficiencies. A weight for a good/stock 
basket is not about the market but about the users desired balance within a basket and a limit 
price is not about the market but about a desire of the user not to pay more for a good than the 
user is willing to pay. This reasoning for the Examiner's hindsight supplementation of the prior 
art is submitted to be faulty. 

As another Example, claim 34 calls for a "database ... basket record" and the Examiner 
has pointed to no part of either of the references where a database record is even mentioned. 
And a review of Belzberg and Stallaert will discover no discussion of database records. The 
Examiner has failed to even establish a minimum basis for rejecting the claims. 

For the above discussed reasons, reversal of the rejection as defective as a matter of 
law is requested. 

C. The Prior Art vs. The Claimed Invention 
Claim 1 

Claim 1 calls for a structure that includes "a server coupled to a goods trading market" 
and "a user computer coupled to the server" where the user computer is used with an interface 
to allow the user to trade a basket and where the server performs the "trading". In contrast, 
Belzberg has a user computer 4 coupled to the market computer 2 that performs the trades (see 
Belzberg figure 1 and col. 2, In. 59+) and Stallaert has a web client 701 coupled to a bundled 
trading processor 707 that performs the bundle trades (see Stallaert, figure 6 and col. 12, In. 
52+). Neither Belzberg nor Stallaert teach or suggest having the structure of the present 
invention. In both cases Belzberg and Stallaert have the processor used by the trader directly 
tied to dedicated trading machines. 

In contrast, the present invention interposes a server that allows connection to the 
multiple trading processors of the market that can consist of multiple trading platforms or 
services (such as NASDAQ, NY Stock Exchange, etc.) This provides increased flexibility in 
making the trade of the basket requested by the user. In addition, the action of submitting and 
actually performing a trade (that is, "trading") includes a number of operations, such as 
submitting a trade request, awaiting a reply as to whether the trade can be wholly or partially 
filled, confirming that the trade should be done, etc. In a situation where a large number of 
fungible goods, such as stocks, can be traded in a basket, the operations with respect to each 
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individual trade can take a considerable period of time. And in stock trading time is of the 
essence as a market can move very quickly. A system that uses a desktop computer is much 
slower than a system that users a server, particularly in an environment where the market 
includes a number of different trading platforms that each have a different trading protocol. In 
addition by using a server, the desktop machines need not worry about and be updated with any 
changes in trading protocol. Such changes can be handled in the server. It is submitted that the 
prior art of Belzberg and Stallaert does not address or solve the problems solved by the structure 
of the present invention. For this reason, it is submitted that the rejection of claim 1 should be 
reversed. 

Claim 1 also calls for the trading of a "basket" specified by the user. As discussed in the 
specification of the present application a basket is a thing that has continuity and characteristics 
of permanency. It exists both before and after a trade occurs and has persistent existence 
independent of any transaction, just like a share of stock exists whether traded or not (see, for 
example, specification pg. 3, lines 4-9. pg.5, lines 20-26 and pg. 6, lines 24-28). That is, the 
user can buy a basket, then decide to sell 1/2 of the basket, that can contain a large number of 
stocks. That 1/2 basket is then traded, leaving 1/2 of the basket remaining. As depicted in 
figure 4, the user can pick a basket to trade, such as the basket named "Matt's Top 20", that was 
created by another trader. This definition of a basket is one that is recognized by those of skill in 
the art of the present invention. For example, those in the business of trading currencies, a type 
of fungible good, have currency baskets. Those of skill in the art recognize that a basket has 
characteristics of permanency. (See basket - 4 a : an aggregate of values (as of selected 
currencies) the average of which serves as a monetary standard b : a selection of financial 
instruments (as equities, futures, or options) the values of which reflect market fluctuations - 
Merriam-Webster Onln. Dictionary copyright © 2005 by Merriam-Webster, Incorporated). 

In contrast, the Belzberg system is a list trading system that uses a spreadsheet to create 
the list. To sell any portion of a previously purchased list of stocks, the user must create a new 
list of sell trades that include the sell amount of each individual stock. That is, a list trading 
system as in Belzberg does not actually trade baskets. Stallaert also does not trade baskets but 
trades bundles, another form of a trade mechanism that requires that the user recreate the 
bundle if the bundle is to be traded again. In the case of Stallaert and Belzberg, the user cannot 
just select a basket but must create the list or bundle each time that the user wants to make a 
list or bundle trade. The list of Belzberg and the bundle of Stallaert would not be considered a 
basket by those of ordinary skill in the art. For this additional reason, it is submitted that the 
rejection of claim 1 should be reversed. 
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Claim 2 

Claim 2 calls for the interface of claim 1 to provide a basket open region where the user 
can initiate the closing of a basket, that is, the disposal of the complete basket whether that 
basket has long (ownership) or short (borrowed) positions. The Examiner has pointed to nothing 
in the prior art that teaches or suggests this. For this reason, it is submitted that the rejection of 
claim 2 should be reversed. 

Claim 3 

Claim 3 calls for the initiation of a basket trade by the interface of claim 2 by the server to 
be by a single initiation action: The Examiner points to Belzberg col. 3, lines 51-67. the text of 
which is set out above. A review of this text relied upon by the Examiner reveals that this text 
says nothing about "a single initiation action". Rather Belzberg calls for the list to be submitted 
for linkage, completion of the spread sheet via the linkage, then the programming of a series of 
commands, and then the submission of the trade commands based on a user input. At least two 
initiation actions are required in Belzberg. For this reason, it is submitted that the rejection of 
claim 3 should be reversed. 

Claim 4 

Claim 4 calls for the interface of claim 1 to include a basket creation region where the 
user can list the goods. The Examiner has pointed to nothing in the prior art that teaches or 
suggests this. For this reason, it is submitted that the rejection of claim 4 should be reversed. 

Claim 5 

Claim 5 calls for the list of goods of the interface of claim 1 , made by the user, to include 
a trade destination, such as one of the markets discussed above. The Examiner has pointed to 
nothing in the prior art that teaches or suggests this. The prior art of Belzberg and Stallaert 
would not provide for such a possibility because they have dedicated single destination trading 
machines where all trades go. For these reasons, it is submitted that the rejection of claim 5 
should be reversed. 

Claim 6 

Claim 6 calls for the interface of claim 1 to include a name field where the user defines 
the name of the basket, an investment amount field where the user specifies an investment 
amount, a buy/sell field, a share threshold field where the user specifies a share trade threshold. 
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a weighting field allowing a user specified weighting, an index type field where the user can 
specify a measurement index, a lot size field where the user specifies a purchase increment. 
The Examiner has pointed to nothing in the prior art that teaches or suggests these features. 
Where, for example, does the prior art include a field where the user can specify a measurement 
index? Additionally, as noted above, claim 6 calls for the interface to include the weighting 
limitation rejected based on the faulty reasoning by the Examiner discussed above. For this 
reason, the rejection by the Examiner should be reversed. The Examiner rejects these 
limitations also for design choice referring to some undefined alleged well known asset trading 
without a line of reasoning other than possibly improper hindsight or improper Examiner 
personal knowledge. For these reasons, it is submitted that the rejection of claim 6 should be 
reversed. 

Claim 7 

Claim 7 calls for the interface of claim 1 to include a basket name field, an investment 
amount field, an assets field where assets of the basket are specified and a weighting field 
allowing a user specified weighting. The Examiner has pointed to nothing in the prior art that 
teaches or suggests these features other than the faulty reasoning discussed above for the 
weighting feature. For these reasons, it is submitted that the rejection of claim 7 should be 
reversed. 

Claim 8 

Claim 8 calls for the interface of claim 1 to include a name field where the user defines 
the name of the basket, an investment amount field where the user specifies an investment 
amount of an order, a minimum amount field where the user specifies a increment for trading the 
basket, a buy/sell field, an order type field where the user specifies a type of order, a limit price 
field where the user specifies a limit price for the basket, an order entry field where the user 
indicate whether the limit order is to be issued based on a condition, a condition field specifying 
a condition for issuing the order, a weighting field allowing a user specified weighting, a variance 
field where the user can specify a variance of the order, a time-in force field where the user sets 
a time limit of the order and an assets field where assets of the basket are specified. The 
Examiner has pointed to nothing in the prior art that teaches or suggests these features other 
than the faulty reasoning discussed above for the weighting and limit pricing features. Where, 
for example, does the prior art include a variance order? The Examiner has also improperly 
based the rejection on design choice referring to some undefined alleged well known asset 
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trading without a line of reasoning. For these reasons, it is submitted that the rejection of claim 8 
should be reversed. 

Claim 9 

Claim 9 calls for the interface of claim 1 to include an investment amount field where the 
user specifies an investment amount of an order and a limit price field and a stop field where the 
user specifies when the order will enter the market. The Examiner has pointed to nothing in the 
prior art that teaches or suggests these features other than the faulty reasoning discussed 
above for the limit pricing feature. Where, for example, does the prior art include a stop field that 
allows the user to specify market entry timing for a basket trade? The Examiner has also 
improperly based the rejection on design choice referring to some undefined alleged well known 
asset trading without a line of reasoning. For these reasons, it is submitted that the rejection of 
claim 9 should be reversed. 

Claim 10 

Claim 10 calls for the server of claim 1 to supply the interface with a summary showing 
existing and potential baskets. The Examiner has pointed to nothing in the prior art that teaches 
or suggests a server performing such a summary supply task. Nor has the Examiner pointed to 
anything in the prior art that shows an interface showing existing and potential baskets. The 
Examiner has also improperly based the rejection on design choice referring to some undefined 
alleged well known asset trading without a line of reasoning. For these reasons, it is submitted 
that the rejection of claim 10 should be reversed. 

Claim 11 

Claim 1 1 calls for the summary supplied by the server of claim 10 to show open baskets, 
gallery baskets and account information. The Examiner has pointed to nothing in the prior art 
that teaches or suggests these features. Where, for example, does the prior art include a 
summary showing a gallery basket, a basket that is continuously updated as to asset value and 
that is staged for execution? The Examiner has also improperly based the rejection on design 
choice referring to some undefined alleged well known asset trading without a line of reasoning. 
For these reasons, it is submitted that the rejection of claim 1 1 should be reversed. 

Claim 12 

Claim 12 calls for the interface of claim 1 to show a relationship between a master 
account and a sub-account. The Examiner has pointed to nothing in the prior art that teaches or 
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suggests these features. Nothing in Belzberg or Stallaert teaches or suggests this and they 
particularly says nothing about sub-accounts or master accounts. The Examiner has also 
improperly based the rejection on design choice referring to some undefined alleged well known 
asset trading without a line of reasoning. For these reasons, it is submitted that the rejection of 
claim 12 should be reversed. 

Claim 13 

Claim 13 calls for the interface of claim 12 to show a sub-account contribution to a 
master account. The Examiner has pointed to nothing in the prior art that teaches or suggests 
these features. Where, for example, does the prior art include an interface showing 
contributions between accounts much less between master and sub-accounts? Nothing in 
Belzberg or Stallaert teaches or suggests this and the Examiner has also improperly based the 
rejection on design choice referring to some undefined alleged well known asset trading without 
a line of reasoning. For these reasons, it is submitted that the rejection of claim 13 should be 
reversed. 

Claim 14 

Claim 14 calls for the interface of claim 1 to have a balancing region where the user can 
specify a balance among goods of the basket. The Examiner has pointed to nothing in the prior 
art that teaches or suggests these features. Examiner has also improperly based the rejection 
on design choice referring to some undefined alleged well known asset trading without a line of 
reasoning. For these reasons, it is submitted that the rejection of claim 14 should be reversed. 

Claim 15 

Claim 15 calls for the balancing region of claim 14 to include a goods list field for a user 
changeable goods list, a weight adjustment field for a user changeable goods weight, a share 
threshold for a user changeable trade threshold, a maintain position field and a trading 
increment field. The Examiner has pointed to nothing in the prior art that teaches or suggests 
these features. Where, for example, does the prior art include a maintain position field and a 
trading increment field where the increments (10 shares, 100 shares, etc.) in which a trade is to 
occur are provided? Nothing in Belzberg or Stallaert teaches or suggests this and the Examiner 
has also improperiy based the rejection on design choice referring to some undefined alleged 
well known asset trading without a line of reasoning. For these reasons, it is submitted that the 
rejection of claim 15 should be reversed. 
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Claim 16 

Claim 16 calls for the balancing region of claim 14 to include a goods list field for a user 
changeable goods list. The Examiner has pointed to nothing in the prior art that teaches or 
suggests this feature. For this reason, it is submitted that the rejection of claim 16 should be 
reversed. 

Claim 17 

Claim 17 calls for the interface of claim 1 to have basket close specifying region allowing 
the user to initiate basket closing that is, the disposal of the complete basket whether that basket 
has long (ownership) or short (borrowed) positions. The Examiner has pointed to nothing in the 
prior art that teaches or suggests this. For this reason, it is submitted that the rejection of claim 
2 should be reversed. 

Claim 18 

Claim 18 calls for the close specifying region of claim 17 to have a selector to specify 
which of the goods of the basket to close. The Examiner has pointed to nothing in the prior art 
that teaches or suggests this. For this reason, it is submitted that the rejection of claim 2 should 
be reversed. 

Claim 19 

Claim 19 calls for the interface of claim 1 to allow the user to list a particular good found 
among plural baskets. Examiner has pointed to nothing in the prior art that teaches or suggests 
these features. Where, for example, does the prior art include the ability to list a stock that is 
found in plural baskets? Nothing in Belzberg or Stallaert teaches or suggests this and the 
Examiner has also improperly based the rejection on design choice referring to some undefined 
alleged well known asset trading without a line of reasoning. For these reasons, it is submitted 
that the rejection of claim 19 should be reversed. 

Claim 20 

Claim 20 calls for the interface of claim 1 to provide a basket detail view that shows the 
details of a basket. Examiner has pointed to nothing in the prior art that teaches or suggests this ' 
feature. The Examiner has also improperly based the rejection on design choice referring to 
some undefined alleged well known asset trading without a line of reasoning. For these 
reasons, it is submitted that the rejection of claim 20 should be reversed. 
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Claim 21 

Claim 21 calls for the interface of claim 1 to provide an asset order view that shows the 
details of asset orders. Examiner has pointed to nothing in the prior art that teaches or suggests 
this feature. The Examiner has also improperly based the rejection on design choice referring to 
some undefined alleged well known asset trading without a line of reasoning. For these 
reasons, it is submitted that the rejection of claim 21 should be reversed. 

Claim 22 

Claim 22 calls for the interface of claim 1 to provide a trade execution view that shows 
the sequence of executions that are used to make a trade. The Examiner has pointed to nothing 
in the prior art that teaches or suggests this feature. The Examiner has also improperly based 
the rejection on design choice referring to some undefined alleged well known asset trading 
without a line of reasoning. For these reasons, it is submitted that the rejection of claim 22 
should be reversed. 

Claim 23 

Claim 23 calls for the interface of claim 1 to provide a basket trading history view that 
shows the history of baskets. The Examiner has pointed to nothing in the prior art that teaches 
or suggests this feature. The Examiner has also improperly based the rejection on design 
choice referring to some undefined alleged well known asset trading without a line of reasoning. 
For these reasons, it is submitted that the rejection of claim 23 should be reversed. 

Claim 24 

Claim 24 calls for the interface of claim 1 to provide an asset search view that allows the 
user to search for assets. The Examiner has pointed to nothing in the prior art that teaches or 
suggests this feature. The Examiner has also improperly based the rejection on design choice 
referring to some undefined alleged well known asset trading without a line of reasoning. For 
these reasons, it is submitted that the rejection of claim 24 should be reversed. 

Claim 25 

Claim 25 calls for the interface of claim 1 to provide an asset move view that allows the 
user to move assets between baskets. The Examiner has pointed to nothing in the prior art that 
teaches or suggests this feature. The Examiner has also improperly based the rejection on 
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design choice referring to some undefined alleged well known asset trading without a line of 
reasoning. For these reasons, it is submitted that the rejection of claim 25 should be reversed. 

Claim 26 

Claim 26 calls for the interface of claim 1 of claim 1 to provide a basket rotate view that 
allows the user to rotate investments between baskets that allows assets, that do not need to be 
purchased or sold, to simply be moved to the new basket. The Examiner has pointed to nothing 
in the prior art that teaches or suggests this feature. The Examiner has also improperly based 
the rejection on design choice referring to some undefined alleged well known asset trading 
without a line of reasoning. For these reasons, it is submitted that the rejection of claim 26 
should be reversed. 

Claim 27 

Claim 27 calls for the interface of claim 1 to provide a gallery view basket view allows the 
user to view the basket values of baskets that are not yet owned but staged for execution. The 
Examiner has pointed to nothing in the prior art that teaches or suggests this feature. The 
Examiner has also improperly based the rejection on design choice referring to some undefined 
alleged well known asset trading without a line of reasoning. For these reasons, it is submitted 
that the rejection of claim 27 should be reversed. 

Claim 28 

Claim 28 calls for the gallery view of claim 27 to show a basket variance that allows the 
user to see how far the value of the basket is from a target. The Examiner has pointed to 
nothing in the prior art that teaches or suggests this feature. The Examiner has also improperly 
based the rejection on design choice referring to some undefined alleged well known asset 
trading without a line of reasoning. For these reasons, it is submitted that the rejection of claim 
28 should be reversed. 

Claim 29 

Claim 29 emphasizes the features found in claims 1-28. The separated and distinct 
reasons for reversal of the rejection of claim 29 are discussed with respect to claims 1-28 above. 
For these reasons, it is submitted that the rejection of claim 29 should be reversed. 

Claim 30 
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Claim 30 calls for an interface that includes a trade list region allowing a user to specify 
goods to be traded as a basket. As discussed above with respect to part of claim 1 , it is 
submitted that the prior art does not teach or suggest the trading of a basket but rather 
addresses trading of a list or a bundle. For these reasons, it is submitted that the rejection of 
claim 30 should be reversed. 
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Claim 31 

Claim 31 calls for the interface of claim 30 to include a trade control allowing the user to 
initiate trading of the goods as a single transaction. As discussed above with respect to claim 3, 
the prior art does not teach or suggest such a single event based trade. Nor does the prior art 
discuss trading the basket in a single transaction. As discussed above, the personal type 
computer of the prior art (Belzberg) creates multiple trade commands and transactions for the 
spreadsheet and these are submitted for trading. The single transaction of the present invention 
is the submitted to the server; the server then creates the trade orders. As discussed above, 
this arrangement is much faster, more flexible in addressing the market of multiple trade 
platforms and more cost effective for updates than the approach of using a personal computer to 
do this. Further the present invention calls for the initiation to be via a trade "control" (see 226 
of figure 6) (See also control - an object in a window or dialog box - webopedia - Copyright 2004 
Jupitermedia Corporation All Rights Reserved and control - 2. In a graphical user interface, an 
object on the screen that can be manipulated by the user to perform an action. The most 
common controls are buttons, which allow the user to select options, and scroll down bars, 
which allow the user to move through a document or position text in a window. Microsoft 
Computer Dictionary. - 4*^ ed. Copyright © 1999 by Microsoft Corporation.) The prior art 
(Belzberg) does not teach or suggest using such a control but rather talks in terms of keystrokes. 
For these reasons, it is submitted that the rejection of claim 31 should be reversed. 

Claim 33 

Claim 33 calls for a computer readable storage controlling a computer to trade a basket 
using a using a trade control. As discussed above with respect to claim 1, the prior art does not 
teach or suggest basket trading and with respect to claim 31 the prior art does not teach or 
suggest trading using a trade control. For these reasons, it is submitted that the rejection of 
claim 33 should be reversed. 

Claim 34 

Claim 34 calls for a basket database including a basket record comprising a basket 
identifier, an investment amount and goods identifiers for at least two fungible goods tradable via 
a goods trading market. As discussed previously, the Examiner has pointed to nothing in the 
prior art that teaches or suggests these features of a basket record. For these reasons, it is 
submitted that the rejection of claim 34 should be reversed. 
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Claim 35 

Claim 35 calls for a system as in claim 1 and the arguments discussed above are 
referred to here. In addition claim 35 calls for an electronic message confirmation of the trade. 
The Examiner has pointed to nothing in the prior art that teaches or suggests this additional 
feature for a basket trading system. Rather the Examiner improperly bases the rejection on 
design choice referring to some undefined alleged well known asset trading without any line of 
reasoning. For these reasons, it is submitted that the rejection of claim 35 should be reversed. 

Claim 36 

Claim 36 calls for the electronic message of claim 35 to include an asset description, a 
trade time, a trade amount and a trade price for the assets and a net asset value for the basket. 
The Examiner has pointed to nothing in the prior art that teaches or suggests these features of a 
basket trade confirmation electronic message. Where, for example, does the prior art include an 
electronic confirmation message for a basket trade that includes a net asset value for the 
basket? Rather the Examiner improperly bases the rejection on design choice referring to some 
undefined alleged well known asset trading without any line of reasoning. For these reasons, it 
is submitted that the rejection of claim 36 should be reversed. 

Claim 37 

Claim 37 calls for the goods traded in a basket of claim 1 to include a number of different 
types of goods not discussed or suggested in the prior art. For example, there is no teaching or 
suggestion in the prior art for basket trading of options, commodities, bonds, derivatives, 
tradable liabilities, warrants, notes, limited partnership interests, foreign currencies, contracts, 
futures, bank loan syndication interests, debts, pollution rights, global warming rights, insurance 
claim interests, debt, and real estate. The Examiner has pointed to nothing in the prior art that 
teaches or suggests these features of a basket trade. For these reasons, it is submitted that the 
rejection of claim 37 should be reversed. 

Claim 38 

Claim 38 calls for a system that includes identification means for identifying a stock 
basket of two or more stocks to be traded via a stock trading market, and trading means trading 
the two or more stocks via the market as a unit. Under 35 USC section 112, paragraph 6 states 
that these means "shall be construed to cover the corresponding structure, material, or acts 
described in the specification and equivalents thereof. The specification describes these means 
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as including ail of the limitations of claim 1-38 plus more. The Examiner has provided no 
specific comments about claim 38. The Examiner has provided no line or reasoning or any 
discussion whatsoever as to how the features described in the specification are taught by the 
prior art. For these reasons, it is submitted that the rejection of claim 38 should be reversed. 

Claim 39 

Claim 39 calls for a system like claim 1 and the discussion thereof is referenced here. In 
addition claim 39 calls for the interface to show a relationship between a master account and a 
sub-account and showing sub-account contribution to the master account, and the server 
allocating trades in the master account to the sub-account. The Examiner has provided no 
specific comments about claim 39. The Examiner has pointed to nothing in the prior art that 
teaches or suggests these features of a basket trade system. Where, for example, does the 
prior art of Belzberg or Stallaert discuss master and sub accounts much less allocating trades 
between them? Rather the Examiner improperly bases the rejection on design choice referring 
to some undefined alleged well known asset trading without any line of reasoning. For these 
reasons, it is submitted that the rejection of claim 39 should be reversed. 

Claim 40 

Claim 40 particularly calls for the means of claim 39 to allocate trades proportional to the 
principle found in master and sub accounts. The Examiner has pointed to nothing in the prior art 
that teaches or suggests these features of a basket trade. Where, for example, does the prior art 
of Belzberg or Stallaert discuss proportional allocation of trades between master and sub 
accounts? Rather the Examiner improperly bases the rejection on design choice referring to 
some undefined alleged well known asset trading without any line of reasoning. For these 
reasons, it is submitted that the rejection of claim 40 should be reversed. 

Claim 41 

Claim 41 calls for the means of claim 39 to allocate trades between master and sub- 
accounts based on defined allocations. The Examiner has pointed to nothing in the prior art that 
teaches or suggests this feature of a basket trade. Rather the Examiner improperly bases the 
rejection on design choice referring to some undefined alleged well known asset trading without 
any line of reasoning. For these reasons, it is submitted that the rejection of claim 41 should be 
reversed. 
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D. Conclusion 

It is submitted that the Examiner has not made a prima facie case of obviousness by 
preponderance of the evidence and reversal of the rejection is requested. 

Respectfully submitted, 

STAAS & HALSEY LLP 
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Washington, D.C. 20005 
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Claims Appendix 

1 . A system, comprising: 

a server coupled to a goods trading market and trading fungible goods via the market; 

and 

a user computer coupled to the server and allowing a user to specify a basket comprising 
at least two fungible goods tradable via the market using an interface to initiate trading by the 
server. 

2. A system as recited in claim 1 , wherein the interface comprises a basket open 
region where the user can initiate closing of the basket. 

3. A system as recited in claim 2, wherein the initiation is by a single initiation action. 

4. A system as recited in claim 1 , wherein the interface comprises a basket creation 
region where the user can list the goods. 

5. A system as recited in claim 4, wherein the list includes a trade destination. 

6. A system as recited in claim 1 , wherein the interface comprises a name field 
where the user defines the name of the basket, an investment amount field where the user 
specifies an investment amount, a buy/sell field, a share threshold field where the user specifies 
a share trade threshold, a weighting field allowing a user specified weighting, an index type field 
where the user can specify a measurement index, a lot size field where the user specifies a 
purchase increment. 

7. A system as recited in claim 1 , wherein the interface comprises a basket name 
field, an investment amount field, an assets field where assets of the basket are specified and a 
weighting field allowing a user specified weighting. 

8. A system as recited in claim 1 , wherein the interface comprises a name field 
where the user defines the name of the basket, an investment amount field where the user 
specifies an investment amount of an order, a minimum amount field where the user specifies a 
increment for trading the basket, a buy/sell field, an order type field where the user specifies a 
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type of order, a limit price field where the user specifies a limit price for the basket, an order entry 
field where the user indicate whether the limit order is to be issued based on a condition, a 
condition field specifying a condition for issuing the order, a weighting field allowing a user 
specified weighting, a variance field where the user can specify a variance of the order, a time-in 
force field where the user sets a time limit of the order and an assets field where assets of the 
basket are specified. 

9. A system as recited in claim 1, wherein the interface comprises an investment 
amount field where the user specifies an investment amount of an order and a limit price field 
and a stop field where the user specifies when the order will enter the market. 

1 0. A system as recited in claim 1 , wherein the server supplies the interface with a 
summary showing existing and potential baskets. 

11. A system as recited in claim 10, wherein the summary shows open baskets, 
gallery baskets and account information. 

12. A system as recited in claim 1, wherein the interface shows a relationship 
between a master account and a sub-account relationship. 

13. A system as recited in claim 12, wherein the interface shows sub-account 
contribution to the master account. 

14. A system as recited in claim 1, wherein the interface comprises a basket 
balancing region where the use can specify a balance among goods of the basket. 

15. A system as recited in claim 14, wherein the balancing region comprises a goods 
list field for user changeable goods list, a weight adjustment field for a user changeable goods 
weight, a share threshold for a user changeable trade threshold, a maintain position field and a 
trading increment field. 

16. A system as recited in claim 14, wherein the balancing region comprises a goods 
list field for user changeable goods list. 
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17. A system as recited in claim 1 , wherein the interface comprises a basket close 
specifying region allowing the user to initiate basket closing. 

18. A system as recited in claim 17, wherein the basket close specifying region 
comprises a goods selector allowing the user to specify which of the goods is to be closed. 

19. A system as recited in claim 1 , wherein the interface comprises a goods 
specifying region where the user can specify the listing of a particular good among plural 
baskets. 



20. A system as recited in claim 1 , wherein the interface comprises a basket detail 
view of basket contents. 



21 . A system as recited in claim 1 , wherein the interface comprises an asset order 
detail view. 

22. A system as recited in claim 1 , wherein the interface comprises a trade execution 

view. 



23. A system as recited in claim 1 , wherein the interface comprises a history view. 



24. A system as recited in claim 1, wherein the interface comprises an asset search 

view. 



25. A system as recited in claim 1 , wherein the interface comprises an asset move 

view. 



26. A system as recited in claim 1 , wherein the interface comprises a basket rotate 

view. 

27. A system as recited in claim 1 , wherein the interface comprises a gallery basket 

view. 
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28. A system as recited in claim 27, wherein the gallery view shows a basket 
variance. 

29. A system, comprising: 

a server coupled to a goods trading market and trading fungible goods via the market; 

and 

a user computer coupled to the server and allowing a user to specify a basket comprising 
at least two fungible goods tradable via the market using an interface to initiate trading by the 
server, wherein the interface comprises: 

a basket open view comprising a name field where the user defines the name of the 
basket, an investment amount field where the user specifies an investment amount, a buy/sell 
field, a share threshold field where the user specifies a share trade threshold, a weighting field 
allowing a user specified weighting, an index type field where the user can specify a 
measurement index, a lot size field where the user specifies a purchase increment and an 
assets field where assets of the basket are specified; 

a basket trade view comprising a name field where the user defines the name of the 
basket, an investment amount field where the user specifies an investment amount of an order, 
a minimum amount field where the user specifies a increment for trading the basket, a buy/sell 
field, an order type field where the user specifies a type of order, a limit price field where the user 
specifies a limit price for the basket, an order entry field where the user indicate whether the limit 
order is to be issued based on a condition, a condition field specifying a condition for issuing the 
order, a weighting field allowing a user specified weighting, a variance field where the user can 
specify a variance of the order, a time-in force field where the user sets a time limit of the order 
and an assets field where assets of the basket are specified; 

a summary view showing existing and potential baskets; 

a relationship view of a relationship between a master account and a sub-account; 
a basket balancing view where the user can specify a balance among goods of the 

basket; 

a basket detail view of basket contents; 

an asset order detail view; 

a trade execution view; 

a history view; 

an asset search view; 

an asset move view; 
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a basket rotate view; and 
gallery basket view. 

30. An interface, comprising: 

a trade list region allowing a user to specify goods to be traded as a basket. 

31 . An interface as recited in claim 30, further comprising a trade control allowing the 
user to initiate trading of the goods as a single transaction. 

32. A method, comprising: 

creating an interface allowing a user to specify a basket of goods to be traded; and 
allowing the user to initiate trading of the goods using the interface. 

33. A computer readable storage controlling a computer by allowing user to initiate 
trading of a basket of goods using an interface having a list of goods of the basket and a trade 
control. 

34. A basket database, comprising: 

a basket record comprising a basket identifier, an investment amount and goods 
identifiers for at least two fungible goods tradable via a goods trading market. 

35. A system, comprising: 

a server coupled to a goods trading market and trading fungible goods via the market; 

and 

a user computer coupled to the server and allowing a user to specify a basket comprising 
at least two fungible goods tradable via the market to initiate trading by the server and the server 
confirming the trade by electronic message to the user. 

36. A system as recited in claim 35, wherein the electronic message comprises an 
asset description, a trade time, a trade amount and a trade price for the assets and a net asset 
value for the basket. 

37. A system as recited in claim 1 , wherein the goods comprise one of stocks, 
options, commodities, bonds, derivatives, tradeable assets, tradable liabilities, a combination of 
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tradable assets and liabilities, financial assets, securities, foreign equities, domestic equities, 
american depository receipts, corporate paper, unit investment trust shares, options, warrants, 
notes, limited partnership interests, private placement securities, foreign currencies, contracts, 
futures, bank loan syndication interests, debts, pollution rights, global warming rights, insurance 
claim interests, debt, and real estate. 

38. A system, comprising: 

identification means for identifying a stock basket of two or more stocks to be traded via 
a stock trading market; and 

trading means trading the two or more stocks via the market as a unit. 

39. A system, comprising: 

a server coupled to a goods trading market and trading fungible goods via the market; 

and 

a user computer coupled to the server and allowing a user to specify a basket comprising 
at least two fungible goods tradable via the market using an interface to initiate trading by the 
server, the interface showing a relationship between a master account and a sub-account 
relationship and showing sub-account contribution to the master account, the server allocating 
trades in the master account to the sub-account. 

40. A system as recited in claim 39, wherein the trades are allocated by the server in 
proportion to principle provided to the master account by the sub-account. 

41 . A system as recited in claim 39, wherein the trades are allocated by the server in 
response to defined allocations. 
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42. A system, comprising: 

a server coupled to a goods trading market and trading fungible goods via tlie market; 

and 

a user computer coupled to the server, where the user computer allows a user to specify 
a basket including at least two fungible goods tradable as a unit via the market using an 
interface to initiate trading by the server, the interface showing a net asset value indicator 
indicating a net asset value reflecting information including changes made to the basket 
contents by asset issuer related events. 
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